GNU virtual private Ethernet

Virtual private networks (VPNs) are designed to overlay a second, secure network on top of the existing (insecure) Internet, but that network overlay can take a number of different forms depending on the precise security needs in question, how static or dynamic the network is, and other factors. GNU Virtual Private Ethernet (GVPE) is a free software VPN suite that takes a different approach to the problem than that of popular projects like OpenVPN. In particular, GVPE creates an actual network where all participating nodes can talk directly to one another, rather than setting up a point-to-point tunnel, and it tries to simplify VPN deployment by making encryption and other settings into compile-time options.

The latest release is version 2.25, from July 2013. Prior to 2.25's release, the last update was from February 2011, and the one before that from 2009. Suffice it to say, then, that GVPE is not a rapidly moving target. But there are several changes in 2.25 that users should take note of. It is also noteworthy, however, that developer Marc Lehmann announced in the release notes that 2.25 would be the final release in the 2.x line—subsequent releases will be changing the underlying message protocol, and will be numbered 3.x to indicate the ABI break.

Background

GVPE is designed to handle a use case most other VPN tools do not: connecting multiple nodes—as in "more than two"—into a single virtual network. The difference is not in how many clients computers can use the VPN, but in how the participating nodes connect. Most other VPN software is optimized for creating site-to-site tunnels that provide a link from one LAN to another, which serves the commonplace usage scenario of connecting to an office VPN from a single laptop or remote home office. For example, a gateway router or a machine on the LAN is set up to serve as an OpenVPN server, creating either a layer-2 (link-layer) or layer-3 (IP layer) tunnel to a remote OpenVPN client, using the kernel's TUN/TAP driver. OpenVPN is generally geared toward IP-layer tunneling, however.

While multiple network sites can be connected in such a fashion, the more sites there are, the more difficult the configuration is to set up and maintain. A separate tunnel needs to be configured between each site and at least one other—either in a star topology with one site serving as a hub, or else with routing rules for each tunnel configured at each site.

GVPE, is designed to simplify this multi-site configuration. It runs separately on each node participating in the VPN, with the same configuration file at each node. The "virtual Ethernet" segment that connects the nodes is, in a sense, a separate network—it provides a network interface for the VPN that exists alongside the normal network. The VPN provides multiple entry points, each client can talk directly to the others, and any node can be taken offline at any time without disconnecting the rest. GVPE is very much a link-layer VPN in this respect; even broadcast Ethernet frames are supported. Consequently, any network protocol stack that can run over Ethernet can run over a GVPE network, which provides considerable flexibility in setting up the virtual network.

On the other hand, the flexibility in GVPE's network topology comes at the cost of a bit less flexibility where the security design is concerned. GVPE uses public-private key pairs for each node to secure its traffic. But the ciphers and digest algorithms that are used must be chosen when GVPE is configured and built (the defaults are RIPEMD-160 for the digest and AES-128 for encryption). The cipher and digest choices are passed to the configure script. Selecting just one of each makes it possible to build smaller binaries (with, in theory, a smaller attack surface). The transport protocols over which GVPE will run (raw IP, UDP, ICMP, TCP, and even DNS are supported) are specified in the configuration file, along with a list of all of the GVPE nodes participating in the virtual network. The nodes can be specified by IP address or by hostname.

Compared to OpenVPN, this configuration file is quite simple; for example, a three-site network could make do with:

    enable-rawip = yes
    ifname = vpn0

    node = site1
    hostname = 192.168.1.100

    node = site2
    hostname = db.example.com

    node = secrethq
    hostname = tahiti.nsa.gov

and be fully connected. On the other hand, the configuration file must be distributed to every node, so adding, removing, or reconfiguring nodes and options necessitates propagating the changed file to all sites. Tools like rsync help, of course, but for large networks it could become a hassle—or worse, should the need arise to quickly remove a node from the VPN. Each node must also have an ifup script for the interface named in the configuration which assigns it an IP address for the private network. Finally, each node needs to have its own key pair created and its public key distributed to all of the other nodes. The private keys need to be distributed to their respective nodes securely, of course.

GVPE provides a command line tool called gvpectrl that can automatically read in the configuration file and create the key pairs needed for each node. Once the configuration file and appropriate keys are all in place, each node can start the GVPE daemon with:

    gvpe -D theappropriatenodename

Subsequently, applications that need to use the private network may need to be configured either for the vpn0 virtual interface or for the private network IP address. Simple applications like ping may require no configuration; others like Apache need to be bound to the specific interface. Apart from being pointed at the VPN, however, applications should work automatically—an IMAP client just needs to know the IP address of its servers, whether they are on the VPN or the Internet. GVPE nodes establish a connection with Elliptic-Curve Diffie-Hellman key exchange, and the packets include hash message authentication codes (HMAC) as checksums.

The protocol header includes the source and destination IDs of each node, so that nodes can route messages. These IDs can be assigned in the configuration file, but by default they are the integer number of the nodes in the order they are listed in the file. That has the benefit of being generic, rather than being taken from (and revealing) some property of the node, like MAC address. Node-to-node traffic is connection-oriented, with sequence numbers in each packet; retries include exponential back-off.

GVPE does not have to run on the actual client machines; it can also be run on gateway routers to connect entire networks. However, the routing configuration in such a scenario is understandably more complex, as is setting up firewall rules to restrict access to the private network. But GVPE is designed to eliminate much of this complexity by running on each client node—one of the project's repeated bullet-point features is that it allows clients to conduct private networking without trusting any of the intermediary network.

The future

GVPE has not changed much in recent releases. Version 2.25 introduces two changes that affect backward compatibility with existing deployments—although neither change demands much reconfiguration.

First, it is no longer possible to enable UDP as the sole transport protocol. The release notes say that this is necessary because, in some situations, nodes need to negotiate their connection to another node without knowing what transport protocols the other node can speak. That negotiation requires contacting a third GVPE node that can act as a router, and UDP's connection-less nature prohibits that negotiation. Second, the DNS transport protocol has been altered; the change breaks compatibility with previous releases (changing the encoding used for SYNs and headers, among other things), although the project warns users to use DNS transport only as a last resort to sneak through stubborn firewalls anyway. Other changes include the addition of the SHA-256 and SHA-512 digests as HMAC options and additional options for configuring the GVPE daemon's chroot behavior.

Considering the fact that changes to the DNS transport and the allowable transport protocol settings may force some current 2.x users to update their configurations, one might well ask what to expect in the forthcoming 3.x series. To that question, Lehmann's announcement only says that the GVPE message protocol itself will change, "to take advances in the last decade into account". What that means is not entirely clear, although he does note how key lengths and hash functions have evolved in the intervening years.

In the meantime, though, GVPE offers an interesting feature set that differs considerably from the "traditional" VPN model. Not only can nodes communicate without trusting the network itself, but the endpoint-to-endpoint encryption means that they do not have to trust other nodes on the network, either. True, the manual propagation of the configuration file and keys does mean that users need to trust the administrator who sets up the system, but that is ultimately true in almost all networks, private and virtual ones included.