content_image/418420.jpg
common network APIs such as Berkeley Sockets allow- ing existing application to work over the VPN without modification. There are many different types of VN de- vices, though due to our focus on an open platform, we focus on TAP [24]. TAP allows the creation of one or more Virtual Ethernet and / or IP devices and is avail- able for almost all modern operating systems including Windows, Linux, Mac OS/X, BSD, and Solaris. A TAP device presents itself as a character device providing read and write operations. Incoming packets from the VN are written to the TAP device and the networking stack in the OS delivers the packet to the appropriate socket. Outgo- ing packets from local sockets are read from the TAP device. 

The VN device can be configured manually through static addressing or dynamically through dynamic host configuration process (DHCP) [11]. Setting the IP ad- dress of the VN device causes the system to add a new rule to the routing table that directs all packets sent to the VPN address space to be sent to the VN device. Pack- ets are read from the the TAP device, encrypted and sent to the overlay via the VPN client. The overlay deliv- ers the packet to another client or a server with a VN stack enabled. Received packets are decrypted, veri- fied for authenticity, and then written to the TAP device. In most cases, the IP layer header remains unchanged, while VPN configuration determines how the Ethernet header is handled. 

The described configuration so far creates what is known as a split tunnel: a VPN connection that han- dles internal VPN traffic only and not Internet traffic . VPNs can also support full tunneling, which allows a VPN client to securely forward all their Internet traffic through a VPN router. This provides network-layer pri- vacy and authentication when a user is in an insecure en- vironment, such as an open wireless network at a coffee shop, by securely relaying all Internet traffic through a trusted third party, the VPN gateway. Both models are illustrated in Figure 2. 

<img src='content_image/418420.jpg'>

Most centralized VPNs implement full tunneling through a routing rule swap, which makes the default gateway an endpoint in the VPN subnet and traffic for the VPN server is routed explicitly to the LAN gateway. For example, in a typical home network, an Internet bound packet will be retrieved at the VN device, encrypted, and sent to the VPN gateway via the LAN’s gateway. At the VPN gateway, the packet is decrypted and delivered to the Internet. A P2P system encounters two challenges in supporting full tunnels: 1) P2P traffic must not be routed to the VPN gateway and 2) there may be more than one VPN gateway. We further discuss this issue and provide solutions to this problem in Section 4.3. 

## 2.2 Centralized VPN Servers 

OpenVPN is an open and well-documented platform for deploying centralized VPNs. We use it as the basis for comparison with our approach, as it provides a rep- resentation of features found in most centralized VPNs. Centralized VPNs are responsible for authentication and routing between clients, providing a NAT to the servers local resources and Internet (full tunnel), and handling inter-server communication. 

Central VPN servers operate at well-known endpoints consisting of a hostname or IP address and a port. In a system containing multiple servers, a client attempt- ing to log in will randomly attempt to connect to one of the servers until successful, implementing a simple load balance. Once connected, clients obtain an address in the VPN address space. Depending on configuration this will allow a client to communicate with other clients, re- sources on the same network as the server, or Internet hosts via the VPN. In such situations, it is important that the client and server both authenticate with each other in using some form of challenge response protocol. 

All inter-client communication flows through the cen- tral server. In the default configuration of OpenVPN, a client encrypts a packet and sends it to the server. The server receives the packet, decrypts it, determines where to relay it, and then encrypts and sends the packet to its destination. This model does not prevent a server from eavesdropping on such communication. While a second layer of encryption is possible through a shared secret, it requires out-of-band communication and is less secure than relying on a PKI. 

To support full tunneling or allow the client to access the server’s resources, the server too must enable client- like features by becoming a VPN endpoint with a VN device. Depending on the configuration, the server can then configure traffic from the VPN to go through a NAT prior to routing it to the LAN and/or Internet. 

OpenVPN allows a distribution of servers, so as to pro- vide fault tolerance and to a lesser degree load balancing. Servers must be configured to know about each other in advance and need routing rules established to forward 

