VPN Type Authentication Method Peer Discov- ery NAT Traversal Availability OpenVPN [42] Centralized Certificates or passwords with a central server Central server(s) Relay through server(s) Open Source tinc [36] Decentralized PKI Broadcast Relay through mesh Open Source CloudVPN [12] Decentralized PKI Broadcast Relay through mesh Open Source Hamachi [26] Centralized P2P Password at cen- tral server Central server NAT traversal and centralized relay limited free-use, limited Non-Windows clients, no private relays GBridge [25] Centralized P2P Password at cen- tral server Central server NAT traversal, cen- tralized relay Windows only, free- ware, no private relays Wippien [30] Centralized P2P Password at cen- tral server Central server NAT traversal, no relay support Mixed Open / Closed source N2N [10] Unstructured P2P Shared secret Broadcast NAT traversal, de- centralized relay Open Source P2PVPN [19] Unstructured P2P Shared secret Broadcast No NAT traversal, decentralized relay Open Source IPOP Structured P2P PKI or pre- exchanged keys DHT look up NAT traversal and relay through physi- cally close peers Open Source Table 2: VPN Comparison packets. Load balancing exists only in the process of the client randomly connecting to different servers and po- tentially with a server refusing connection due to load. The current approach lacks a distributed load balance. Two examples of systems that assist in distributing load in VPN systems are tinc [36] and CloudVPN [12]. Unlike the decentralized P2P systems, these decentral- ized systems lack the ability to self-organize the VPN and require explicit specification of which links to create. This means that, like OpenVPN, these systems can suffer VPN outages when nodes go offline. The difference be- ing that OpenVPN makes it explicit who is a server and who is not, whereas in tinc and CloudVPN anyone can be a server or a client. In the typical tinc and CloudVPN setup, individual users share endpoints with each other out of band and then place them in the VPN configura- tion file. Due to the lack of self-configuration, members in the system will not replace links as members go of- fline. Hamachi [26] began the advent of centralized VPNs that went with the ambiguous moniker “P2P VPN”. In reality, these systems would be best classified as central- ized VPN servers with P2P clients. Specifically, the na- ture of P2P in these [30, 25] types of systems provides direct connectivity between clients once authenticated by a central server. While direct connection is desirable, it does not always happen due to firewalls or impenetra- ble NATs. When this happens, the central server either 2.3 Centralized P2P VPN Systems 2.4 P2P VPN Client / Server Roles acts as a relay, if not, the two machines are unable to communicate. One concern is that each of these imple- mentations uses their own security protocols that involve using a server to verify the authenticity and setup secure connections between clients. Most of these projects are closed preventing users from hosting their own authen- tication servers and relays. This model forces users to trust the third-party server to not eavesdrop or perform other man-in-the-middle attacks. None of these provide support for full tunneling. Unlike centralized systems, pure (or decentralized) P2P systems have no concept of dedicated servers, though it is entirely possible to add reliability to the sys- tem by starting dedicated instances of the P2P VPN. In these systems, all participants are members of a collec- tive known as an overlay. Current generation P2P de- centralized VPNs use unstructured P2P networks, where there are no guarantees about distance and routability be- tween peers. Two popular examples of unstructured P2P VPNs are N2N [10] and P2PVPN 1 [19]. As a result, par- ticipants tend to be connected to a random distribution of peers in the overlay. Finding a peer requires some form of broadcasting, either announcements or searches, to the entire overlay. While unstructured P2P systems have some scalability concerns, P2P systems in general $^{1}$Due to the similarities between the name P2PVPN and focus of this paper, we use “P2PVPN” to refer only to [19] and “P2P VPN” to refer explicitly to our approach. 4