VPN


As good as being there.

A Virtual Private Network, or VPN, is an extension of a private network across a public network, making it possible to access the private network's resources when not directly connected to it.

They work by establishing a secure tunnel through an insecure network like the internet and passing network traffic through the tunnel. They can encrypt and compress the data to increase security and performance.

The Linux Universal TUN/TAP device driver provides virtual network devices that interface with user-space programs instead of physical network media. It offers two kinds of virtual network device:

  • The tun (tunnel) device works with ethernet frames (i.e in OSI layer 2, the data link layer).

  • The tap (network tap) device works with IP packets (in OSI layer 3, the network layer).

In other words, the tap is a virtual ethernet device and the tun is a virtual IP point-to-point device.

The TUN/TAP driver is used by many networking applications designed to provide tunnelling and virtual networking, for example vTun, OpenSSH and OpenVPN.

A VPN can be created at either layer 2 or 3, each with their own advantages and disadvanges that may or may not be important depending on the anticipated use of the VPN.

  • The layer 2 VPN operates below the IP protocol and can therefore carry other kinds of traffic and can be bridged to extend the local network across the VPN without the need for layer 3 routing but can result in a higher level of network noise (such as broadcast traffic) on the VPN.

  • The layer 3 VPN creates a separate IP subnet and requires routing if data is to be transmitted outside that subnet. It only supports IP traffic.

The typical configuration of a VPN will be either bridged (Layer 2) or routed (Layer 3).

  • A bridged VPN places connecting clients into the private network. Clients have direct access to anything on that network without the need for any additional routing. The server requires a bridged network interface and a network tap, so the set-up is slightly more complex. This kind of VPN operates at the data link layer (Layer 2), typically Ethernet and uses a tap virtual device.

  • A routed VPN creates a separate subnetwork for connecting clients. Additional network routes are required if clients need to see beyond the VPN server host. This kind of VPN operates at the network layer (Layer 3), and uses a tun virtual device. Layer 3 routing cannot pass non-TCP traffic.

The bridged VPN is more transparent to the end-user and worth the additional, but minimal, server configuration effort.

A Tap is a virtual NIC. It can transport any network protocol (IPv4, IPv6, IPX, etc) because it passes layer 2 ethernet frames across the VPN tunnel. Being a NIC, it can be used in a bridge.

Tap has a higher overhead because it carries broadcast data and packets are encapsulated in ethernet frames. Aparently it scales poorly.

A Tun can only transport layer 3 IP packets. It isn't a NIC and cannot be bridged.

This article presents some ways to implement a virtual private network using OpenSSH and OpenVPN.

OpenSSH

OpenSSH, since version 4.3, can use the TUN/TAP device to provide an encrypted tunnel that is, per its documentation (man ssh), suitable for ad-hoc usage.

Since an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups...

SSH uses TCP. Tunnelling TCP over TCP is generally considered a bad idea.

A SSH tunnel can carry ethernet frames or IP packets (this difference being controlled by configuring its PermitTunnel attribute to either ethernet, point-to-point or yes for both; the default is no and disables tunnelling).

To establish a tunnel from client-host to server-host, issue the command on client-host as root:

$ ssh -w a:b server-host

where a and b are integers and are the device numbers assigned at the client (a) and server (b) which ip link will reveal:

# ip link 
17: tun7: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 500

SSH will create a point-to-point tun (layer 3) tunnel by default. An Ethernet (layer 2) tunnel must be explicitly requested:

# ssh -o Tunnel=ethernet -w a:b server-host

which will create a tap tunnel instead:

# ip link
18: tap7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 500
link/ether 46:6b:bb:00:44:29 brd ff:ff:ff:ff:ff:ff

The above commands will also start an unwanted remote shell as well as creating the tunnel, but ssh will fork and run in the background, preventing this if -fNT is added to the command-line. The -f instructs it to fork, -N states that there is no command to execute and -T avoids unnecessary creation of a pseudo-terminal (given there is no command, a terminal isn't needed).

To use the tunnel, bring it up at each end:

# ip link set up tap0

The tunnel can be used directly; to assign an IP address to a tap or tun interface:

# ip addr add 172.16.0.1/16 broadcast 172.16.255.255 dev tap0

Alternatively, bridging or routing can be used to connect one or both ends of a tunnel to other networks.

Notes

  • Both local and remote users require the ability to establish the tun or tap devices. This usually requires that root is used but it can be any account that has the CAP_NET_ADMIN Linux Kernel Capability.
  • If you see channel 0: open failed: administratively prohibited: open failed then check the setting of PermitTunnel (restart server if necessary) and that you are using root (or other user with CAP_NET_ADMIN) from the client.

See also

Port forwarding tunnels

As well as Layer 2/3 tunnelling, OpenSSH can also tunnel between local and remote ports. The -L option forwards a local port to a port on a remote host (a node on the SSH server's network) and the -R option forwards a remote port to a port on a local host (a node on the SSH client's network):

To listen locally for connections on port 1234 and send to port 5678 on some_node_there, a node on the server's network:

$ ssh -fNT -L 1234:some_host_there:5678

To listen remotely for connections on port 1234 and send to port 5678 on some_node_here, a node on the client's network:

$ ssh -fNT -R 1234:some_host_here:5678

The use of -R is commonly described as a Reverse SSH Tunnel and can be used to bypass firewalls and other nefarious purposes.

OpenVPN


OpenVPN is a cross-platform VPN that offers a more robust solution than SSH. Itcan run over either TCP or UDP, the latter being more efficient; it uses SSL/TLS for encryption and supports OSI Layers 2 (tap) and 3 (tun). The OpenVPN Wiki offers a good introduction.

OpenVPN runs a dedicated server that listens on the IANA-assigned port 1194 named openvpn (see /etc/services). It can be configured to use either UDP or TCP but can run multiple instances and can therefore support both at the same time.

Each instance, both client and server, is defined by a configuration file that convention names like /etc/openvpn/<vpn-name>.conf. There are examples supplied in /usr/share/openvpn/examples - see server.conf and client.conf.

OpenVPN uses a Public Key Infrastrucure (PKI) and provides a utility called easy-rsa to manage it (see the ArchLinux Wiki). It produces a number of files:

  1. Certificate Authority (CA) private key: ca.key
  2. CA certificate (contains CA public key): ca.crt
  3. Server private key: server.key
  4. Server certificate (contains server public key): `server.crt)
  5. Per-client private key: client.key
  6. Per-client certificate (contains client public key): `client.crt)
  7. Difie-Hellman parameters: dh2048.pam
  8. secret Hash-based message authentication code (HMAC): ta.key

! The key files should be kept secret (e.g. with filesystem 600 permissions).

The server requires ca.crt, server.key, server.pem, dh2048.pem and ta.key.

The client requires ca.crt, client.key, client.pem and ta.key.

Convention suggests that these files are placed in /etc/openvpn and referenced in the configuration file, for example:

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh2048.pem
tls-auth /etc/openvpn/ta.key 0

! The tls-auth stanza has a trailing 0 on the server and a 1 on the client.

Other configiration items drop privileges to nobody, define the port, protocol, device and, for the server, whether it's routing or bridged.

user nobody
group nobody
port 1194
proto udp
dev tap0

! Dropping privileges prevents automatic route tear-down because the required privileges are no longer held. This results in an error RNETLINK answers: Operation not permitted.

The VPN server/client can be started in the foreground for testing:

$ openvpn /etc/openvpn/server.conf

Or by systemd:

$ systemctl enable openvpn@server
$ systemctl start openvpn@server

Multiple instances can run concurrently but they need to use different ports.

Bridge

An OpenVPN configured to use tap devices can allocate IP addresses for its clients for the bridged subnet. Configure thus:

server-bridge 10.0.100.11 255.0.0.0 10.1.0.0 10.1.0.50

The server-bridge configures the VPN to allocate IP addresses from the pool 10.1.0.0 thru 10.1.0.50.

Take care that the VPN address pool doesn't clash with any DHCP server pool.

Routing

An OpenVPN configured to use tap or tun devices can allocate IP addresses for its clients. Configure thus:

server 172.16.1.0 255.255.255.0

This configures the VPN to allocate IP addresses from the pool 172.16.1.0 thru 172.16.1.255.

Configure the client to route all traffic through the VPN; this changes the client's default gateway to point to the VPN server:

redirect-gateway def1

or push it from the server:

push "redirect-gateway def1"

The def1 argument is explained on the OpenVPN man page and succinctly here.

Basically, it adds two routes (0.0.0.0/1 and 128.0.0.0/1) that cover the whole address range rather than one (0.0.0.0/0). Being more specific, the pair of routes take precdence over a single one.

Another consideration is the Maximum Transfer Unit (MTU) which specifies how much data can fit into a single IP packet. This can be determined automatically if the client's configuration contains the mtu-test option.

! This option cannot be pushed from the server - push "mtu-test" does not work.
See also:

IPSec

An IPsec VPN tunnel is secured with multiple layers of security.

There are two parts to setting up IPsec based VPN tunnels.

  • Internet Keying Exchange protocol (IKE)
  • IPsec protocol

Some points about IPSec

  • Layer 3 (it cannot tunnel layer 2 ethernet frames, unlike OpenVPN).
  • The IPSec protocol requires special consideraton for Nat Traversal (NAT-T).

Linux implementations

! The name swan is an acronym for secure wide area networking.

Which one to use?

Networking Overview

An overview of networking may prove helpful to understand the aims and implementation of a VPN.

The OSI Model

The seven-layer Open Systems Interconnection (OSI Model, ISO/IEC 7498-1) is a standard definition that is used to describe computer networks. Layers 2, 3 and 4 are of interest when configuring a VPN.

An alternative and simplified mode is the Internet Protocol Suite (or the TCP/IP or DoD Model). This compresses the seven OSI layers into four, with the functions of OSI Layer 2 in its Link (or Network Access) layer and OSI Layer 3 being represented by its Internet layer.

A network is a set of connected nodes such as computers, printers or, these days, televisions and so-on. The extent (reach) of a network can be described within the context of layers 2 and 3 of the OSI model.

The extent of a layer 2 network is typically a Local Area Network (LAN), whereas a layer 3 can incorporate a Wide Area Network (WAN).

The term network best describes the collection of nodes connected at layer 2, with the broader internetwork describing a collection of nodes connected at layer 3 (the proper noun "Internet" describing one such internetwork).

A layer 2 network may be made of physically distinct segments that are connected by devices called bridges, or switches. Segmentation can improve performance by reducing the size of a collision domain.

The Internet Protocol (in Layer 3) may logically subdivde an inter-network into subnetworks (subnet). Passing data between subnetworks requires routing.

Data passes through a network in chunks that are called frames in layer 2 and packets in layer 3. The data is encapsulated in packets and these are encapsulated within frames.

A VPN connects two subnetworks on disparate networks in such a way that a node can exist on both subnetworks at the same time. The extent of the subnetworks can range from one to many nodes depending on the VPN configuration used.

Frames are made by hardware such as network interface cards (NICs) whereas packets are generated in software like an Internet Protocol driver.

Packet data is already encapsulated by higher level protocols; the Transmission Control Protocol (TCP) creates a Segment containing a Datagram formed by a higher-level protocol such as HTTP. All of these encapsulations introcduce overhead due to their control information (e.g. headers) that's transmitted in addition to the data payload.

OSI Layer 2, the Data Link Layer

The data link layer is responsible for media access control, flow control and error checking.

Layer 2 chunks of data are called frames.

The Ethernet and Wi-Fi operate in Layer 2. Other technologies found here include Token Ring, the Serial Link Interface (SLIP) and Point to Point Protocol (PPP).

Devices connected at layer 2 form a network as opposed to an internetwork. Layer 2 performs Media Access Control (MAC) and Logical Link Control (LLC). Communication between disparate networks requires a bridge, Hub or Layer 2 switch, the latter two being a multi-port variant of the former. Hubs emit packets to all ports whereas switches learn which port a destination is connected to.

In Layer 2, devices are identified by their 48-bit MAC address (also known as an Ethernet Address), being a 24-bit Organizationally Unique Identifier plus a 24-bit device address.

Relay device = Bridge

OSI Layer 3, the Network Layer

Layer 3 chunks of data are called packets.

The network layer is responsible for packet forwarding; it's where routing between networks happens using either a Layer 3 switch or a router. Unlike switches, routers are software controlled and can support different WAN technologies.

It's here that specific network protocols become relevant

The Internet Protocol (IP) operates at Layer 3 and gives devices IP addresses.

In Layer 3, devices are identified by their IP address.

Layer 3

Relay device = Router

Other Layers

Layer 4, the transport layer, is the home of the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Both build on the Internet Protocol, which leads to the term TCP/IP (but the term UDP/IP isn't really used). The Internet Message Control Protocol (ICMP, used by ping) is another one from Layer 4.

  • TCP is connection-oriented, guaranteed delivery, slower, heavy-weight, error checking with recovery and acknowledgement.
  • UDP is connectionless, no guaranteed delivery, faster, light-weight, error checking but no recovery and no acknowledgement.

Layer 7, the Application Layer, is the home of the application protocols such as HTTP, SMTP, DHCP and so-on.

Further Reading

IP Routing and Forwarding

A network node (e.g. a computer) would have a network interface card (NIC) so that it can connect to other nodes. A node can have more than one NIC.

Each NIC is assigned an IP address and Netmask, placing it in a subnet and giving the node direct access to other nodes within that subnet. A node with multiple NICs, each on a different subnet, has direct access to all of those subnets.

Routing allows a node to access nodes outside its subnets via another node within its own subnets that is a router (or gateway) to the world beyond. This is fundamental to the design of the Internet Protocol.

A node's routing table tells it about the other nodes that it can use in this way and, in particular, about its default gateway - the node that it should use for anything not otherwise specified by the table. The table contains so-called static routes that can be manipualted with the ip route command from iproute2.

! there is also the route command, part of the deprecated net-tools suite.

A router is a device with multiple NICs that can accept packets on one and transmit them on another. The Linux kernel can act as a router; it calls this behaviour IP Forwarding. It's enabled like this:

# echo 1 > /proc/sys/net/ipv4/ip_forward

When IP forwarding is enabled, packets that are received on one interface but destined for a subnet on another are retransimitted onto the other interface.

Without IP forwarding, although a node can access the subnets on all of its interfaces, any packets it receives from other nodes that aren't for it are dropped.

A route between two nodes, A and B, must be defined in both directions so that A can send to B and B can send to A.

An alternative to adding a route to the VPN onto every node on the home network, the route can be added to the existing default gateway. For example on a SpeedTouch router:

{admin}=>ip rtadd dst=172.16.0.0 dstmsk=255.255.0.0 gateway=10.0.100.11

Bridging

A bridge allows multiple ethernet interfaces to be joined together, allowing the tunnel (e.g. tap0) to be joined to another of the server's NICs (say eth0) allowing its network to extend through the tunnel to the client.

! Bridging joins layer 2 network segments; only tap devices may be bridged.

Bridging creates a virtual network interface (e.g. /dev/br0) that acts as a union of the bridged interfaces. The Internet Protocol at Layer 3 then uses the bridge interface (i.e. /dev/br0 is assigned an IP address instead of /dev/eth0).

Because a bridge operates beneath the IP layer, IP traffic traverses it without the need for routing, as does other protocols too.

The brctl command from the bridge utilities (br-utils) is the user-space tool used to configure bridged interfaces:

# brctl addbr br0            # create bridge
# brctl addif br0 tap0 eth0  # add interfaces
# ip link set up tap0        # bring the tunnel up
# brctl show                 # review it
bridge name    bridge id      STP   enabled interfaces
br0    8000.00301bb5799c   no    eth0
                                 tap0

If the server end of the tunnel is bridged to a network that has a DHCP server, the client can obtain an address from it (both ends of the tunnel need to be UP):

# dhcpcd tap0

The client end may also be bridged to extend the network's reach further.

Alternatives

There are other VPN/tunnelling implementatopms; some of them are listed below.